Context

Related to #720, attempts to solve the issue with NextAuth's AUTH_URL and Expo.

See relevant comments:

• feat: expo auth #720 (comment)
• feat: expo auth #720 (comment)
• feat: expo auth #720 (comment)
• feat: expo auth #720 (comment)
• feat: expo auth #720 (comment)
• https://github.com/t3-oss/create-t3-turbo/pull/720#issuecomment-2120709037#1034

Highlights

• general:
  • add a system to generate/infer certain env vars for running the apps in development mode
  • the generation/inference is tied in turbo, so it will run before any of the projects (so they are visible to any app)
• nextjs
  • launches the app with a custom hostname, so it's available though LAN
  • has a script that writes the env vars (infered from api and auth packages)
• expo
  • reads the API URL from an env var (which in development is infered from hostname and port of the nextjs app)

Benefits

• should need 0 initial config related to AUTH_URL (which was the initial objective)
• expo's API URL is better constructed (for example, will respect the port)
• nextjs app is accessible through LAN (useful to access from mobile phone?)
• everything is still configurable from .env in workspace root
• expo API URL on production will be read from env var
• minimal runtime code has been modified

Drawbacks

• nextjs app must be accessed from the network IP instead of localhost (it's shown when the app has started)
• any change in network devices will affect in the nextjs accessible address. The worst part of this is that oauth redirects need to be whitelisted in certain providers (ex: Discord), so this is a bit annoying as new ones need to be added
• inference logic may fail depending on the device/system (though note that .env has full control if env vars are specified there)
• the approach may be incorrect/too complex - I'm biased on this so I'll let others judge!

Screen-capture

Screenshots

TODO

• Document how to manage env vars when doing a production build of the Expo app